Skip to content

Conversation

@PaulGD03
Copy link
Member

@PaulGD03 PaulGD03 commented Oct 4, 2025

This pull requests initial NanoDLP support, implementing and activating NanoDLP HTTP Clients and Models.

The branch does not add additional features, it only allows rewiring Orion to accept the NanoDLP backend to perform already implemented tasks such as:

  • Browsing print files
  • View file details
  • Start and monitor prints
    • Pause and Cancel
  • Moving the Z axis, including Homing.

Additionally, some refactors have been made to DetailsScreen and StatusScreen to optimize information density.

…ration and adjust UI accordingly

- no need to show a USB/Internal Switcher, NanoDLP combines the list.
- Added NanoStatus model to represent the status of the NanoDLP device.
- Created NanoDlpHttpClient to handle communication with the NanoDLP API, including status retrieval and file management.
- Implemented mapping functions to convert NanoDLP data structures to Odyssey-compatible formats.
- Introduced thumbnail generation functionality for visual representation of files.
…seyClient and FakeOdysseyClientForThumbnailTest
@PaulGD03 PaulGD03 self-assigned this Oct 4, 2025
@PaulGD03 PaulGD03 added API API-Level Changes User Interface GUI Changes Utility Utility Changes labels Oct 4, 2025
@PaulGD03 PaulGD03 added this to the NanoDLP Integration (Athena) milestone Oct 4, 2025
@PaulGD03 PaulGD03 changed the title Introduce Basic NanoDLP Support feat: Introduce Basic NanoDLP Support Oct 8, 2025
…spinner logic for improved UI responsiveness
…ion to 'Use Custom Backend URL'

- we can use alternative backends now
…eature flag accessors

- preparing for Athena-specific features
Base automatically changed from api_refactor to dev October 19, 2025 15:29
@PaulGD03 PaulGD03 marked this pull request as ready for review October 21, 2025 11:11
@PaulGD03 PaulGD03 requested a review from ada-phillips October 21, 2025 11:11
Copy link
Collaborator

@ada-phillips ada-phillips left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it mostly looks good? A few concerns/comments tho.

Comment on lines +48 to +49
this.cancelLatched,
this.pauseLatched,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand what these are for?

Future<bool> canMoveToTop();
Future<bool> canMoveToFloor();

/// Move the Z axis directly to the device's top limit if supported.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we do full method docs for each of these for consistency?

Comment on lines +49 to +50
Future<bool> canMoveToTop();
Future<bool> canMoveToFloor();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These feel unnecessary? We should either just be able to catch the unimplemented exception and surface it sensibly to the UI, or, better yet, just use the manual move endpoint to achieve the same functionality :P

Comment on lines +163 to +175
@override
Future<bool> canMoveToTop() async => true;

@override
Future<bool> canMoveToFloor() async => true;

@override
Future<Map<String, dynamic>> moveToTop() async =>
throw UnimplementedError('moveToTop not supported by Odyssey backend');

@override
Future<Map<String, dynamic>> moveToFloor() async =>
throw UnimplementedError('moveToFloor not supported by Odyssey backend');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See previous comment about making this functionality work with Odyssey.

Also, are the canMoveTo_ methods supposed to be returning true?? 💀


@override
Future<Map<String, dynamic>> emergencyStop() async {
return await manualCommand('M112');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want a dedicated emergencyStop endpoint on Odyssey?

Comment on lines +479 to +481
_deviceStatusMessage =
(raw['device_status_message'] ?? raw['Status'] ?? raw['status'])
?.toString();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this something we want to add to Odyssey?

child: Scaffold(
appBar: AppBar(
title: Text(_meta?.fileData.name ?? widget.fileName),
title: Text('Print Details'),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't recall, what was the reason for this change?

Comment on lines +194 to 195
if (_isNanoDlp) return 'Print Files';
return _isUSB == false ? 'Print Files (Internal)' : 'Print Files (USB)';
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if we should do some significant refactoring of how this works on Odyssey, and just have a notion of multiple file locations with config-assigned titles?

That could make this easier/more-agnostic too, because you could just use "Print Files${dirTitle!=null ? ' ($dirTitle)' : ''} or something
which would just give you Print Files for nano, or things like Print Files (Internal), Print Files (USB 1), etc., for Odyssey


// If it's a subdirectory of the default directory, only show the directory name
if (_apiErrorState) return 'Odyssey API Error';
return "$directory ${_isUSB ? '(USB)' : '(Internal)'}";
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The line above this, the Odyssey API Error, should probably change to Backend Error or smth

*/

import 'dart:io';
// dart:io not needed once thumbnails are rendered from memory
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove dead code?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

API API-Level Changes User Interface GUI Changes Utility Utility Changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants